OWASP SAMM acotado a equipos ágiles

En muchos de mis trabajos con clientes, la colaboración suele estar limitada a áreas específicas. Esto plantea un desafío: ¿cómo mejorar la seguridad sin intervenir todo el ciclo de vida del software?

Y ahí es donde me topé con un proyecto interesante que era necesario mejorar en los aspectos de seguridad en los equipos de desarrollo. Para estos casos, lo mejor es seguir los estándares de madurez en seguridad y aprovechar las herramientas de medición como, por ejemplo, OWASP SAMM. Pero al comenzar el proyecto me encontré con este impedimento: necesitaba que fuera acotado el alcance al foco puntual, en este caso al equipo de desarrollo y no en todo el proceso del ciclo de vida del desarrollo del software, o dicho de otra forma, todo el ámbito de DevSecOps.

Por eso, para quien no lo conozca o se encuentre en una situación similar, les dejo en este post mi experiencia y alguna que otra recomendación sobre OWASP SAMM Agile Guidance.

Contexto #

Después de revisar los diferentes modelos de madurez para DevSecOps que normalmente utilizo o me baso, como lo son OWASP SAMM o DSOMM, entre otros, me encontré con este dilema donde muchos temas del modelo completo no eran relevantes para este contexto específico. Y es ahí donde pude dar con una solución que, hasta ese momento, no conocía: OWASP SAMM Agile Guidance.

Como su nombre indica, OWASP SAMM Agile Guidance deriva directamente de OWASP SAMM, y tiene partes de él como también la documentación oficial está en el mismo lugar.

Para comparar, armé el siguiente gráfico basado en el original de OWASP SAMM v2 donde se presentan las áreas funcionales (Business Functions), lás prácticas de seguridad (Security Practices) asociadas a cada área y por cada práctica dos líneas de madurez (Streams A y B) que cada una posee tres objetivos puntuales de mejora con niveles de completutud.

En el gráfico se presenta en gris las prácticas y streams del OWASP SAMM que no se consideran en el Aguile Guidance.

En resumen, OWASP SAMM Agile Guidance plantea que de las 5 funciones de negocio solo quedan 3:

• Gobierno
• Diseño
• Verificación

Donde las prácticas que se mantienen son 6 de 15, y dentro de las prácticas, algunos de las líneas de madurez (streams) no serian considerados quedando en 8.

Mis opiniones #

Creo que alguna vez lo dije, no me gusta reinventar la rueda y por eso me gustó mucho encontrar esta opción para aprovechar lo que ya existe. Lo que pasa en este caso, es que a pesar de que ya exista, tiene sus diferencias con su “padre” (OWASP SAMM). Por eso, resumo los temas que donde considero se diferencian.

Temas a comentar:

• Acotado a los equipos
• Áreas funcional implementación no aparece
• Falta de herramientas de evaluación
• Recomendaciones y Pitfalls por fuera del modelo
• Niveles de OWASP SAMM orientados a DevSecOps
• Respaldo de buenas prácticas de seguridad

Acotado a los equipos #

Es por este tema que llegué a este modelo. OWASP SAMM es abarcativo respecto a Seguridad Aplicativa, lo cual está bien y es el camino adecuado generalmente, pero el Agile Guidance está acotado para los equipos de desarrollo ágil, y es otra perspectiva en la madurez de seguridad que es necesario poder abordar. Por eso lo veo como un punto importante a volver a mencionar: que le hayan dado este espacio para que exista. Porque por ejemplo, el proyecto que mencioné antes, el desafío era mejorar su postura de seguridad sin afectar la velocidad de entrega. OWASP SAMM Agile Guidance nos permitió identificar prácticas clave en el ambito del equipo, como conociminetos y definición de requerimientos de seguridad, sin proponer cambios innecesarios fuera del ámbito del equipo como pueden ser temas en el mundo de la operación.

Áreas funcional implementación no aparece #

Así como no existe el área funcional de Operación, tampoco esta la de Implementación, pero a diferencia del otro, este caso me pareció chocante al principio cuando descubrí que faltaba. 😭

Pero luego, reflexionando más a fondo, entendí que mi expectativa venía desde una mirada centrada en el proceso técnico de entrega —en las herramientas, automatizaciones y flujos de CI/CD que forman parte del ciclo de vida del software en entornos DevOps o DevSecOps.

OWASP SAMM Agile Guidance, en cambio, no pone el foco en el ciclo técnico completo, sino en el equipo ágil como unidad funcional, y en cómo puede adoptar prácticas de seguridad que se integren naturalmente a su forma de trabajar. En ese sentido, la guía busca adaptar SAMM a la realidad del equipo de desarrollo ágil, no a la cadena completa de entrega.

Desde esa perspectiva, tiene sentido que la implementación como área funcional desaparezca: sus prácticas (como el análisis estático, pruebas automatizadas, integración de herramientas en el pipeline, etc.) pueden redistribuirse o quedar implícitas dentro de otras áreas como Construcción (Build), Verificación o Diseño, según cómo se aborden desde el equipo.

Falta de herramientas de evaluación #

Este fue el tema que más me interesaba desde el inicio: contar con una herramienta que me permitiera evaluar el estado actual del equipo y, a partir de ahí, construir un roadmap de mejoras realista y accionable.

En el SAMM tradicional contamos con opciones como la hoja de cálculo oficial (el archivo Excel) o la versión web dockerizada, que permiten realizar la autoevaluación guiada y obtener un resumen visual del nivel de madurez en cada stream. Son herramientas clave para facilitar conversaciones con los equipos y establecer prioridades concretas.

Sin embargo, al trabajar con la guía ágil, me encontré con que no existía una herramienta predefinida ni oficial para aplicar el modelo en este contexto. Esto me llamó la atención porque justamente uno de los objetivos principales de SAMM es permitir la evaluación y planificación iterativa de mejoras, algo muy alineado con el enfoque ágil.

Frente a esta ausencia, decidí crear una versión acotada de la hoja de cálculo original, adaptada específicamente para medir las prácticas sugeridas por la guía ágil.

El objetivo fue principalmente para facilitar una medición rápida manteniendo solo las prácticas de seguridad del formato original que coinciden con la guía agíl. Lo que implica que el modelo de puntuación se modifica para que calcule sobre las 8 líneas de madurez que mantiene la guía.

Aprovechando que ya estaba generando cambios, he modificado la comparación con la Fase 1 de manera que presente resumido los valores actuales versus los propuestos para la primera fase.

Este cambio me pareció interesante aplicarlo porque es algo que normalmente utilizo para resumir al presentar los objetivos de mejora.

Que a diferencia del resumen original cuand utilizo OWASP SAMM no lo puedo extraer directamente si no es modificando. Dejo como referencia la misma sección pero en su versión orginal:

Recomendaciones y Pitfalls por fuera del modelo #

Además de reconfigurar las prácticas de seguridad del modelo OWASP SAMM desde una óptica ágil, la guía incluye algo que considero fundamental y diferenciador: una serie de recomendaciones y advertencias sobre trampas comunes (pitfalls) que no están estrictamente dentro del modelo, pero que son clave para aplicar SAMM de forma efectiva en equipos ágiles.

Estas observaciones van más allá de las prácticas formales. Funcionan como contexto adicional, consejos prácticos y recordatorios de sentido común que muchas veces marcan la diferencia entre una implementación superficial y una integración genuina de la seguridad en el día a día del equipo.

Lo valioso de estas recomendaciones es que aportan realismo, porque termina presentando situaciones típicas que ocurren a diario al intentar incorporar mejoras en Seguridad.

En mi opinión, esta capa de recomendaciones y pitfalls es lo que le da vida y sentido práctico al enfoque ágil de SAMM. Actúa como el puente necesario entre un modelo estructurado y un entorno dinámico. Muchas veces, el éxito o el fracaso de una adopción de seguridad en un equipo ágil no depende tanto del “qué” se quiere implementar, sino del “cómo” se presenta, se comunica y se ajusta al contexto real. Y esta sección ayuda justamente con eso.

Niveles de OWASP SAMM orientados a DevSecOps #

El desarrollo de la herramienta de medición para la Guía Ágil también me permitió identificar cuáles de las líneas de madurez del modelo base de OWASP SAMM conservan su relevancia en este nuevo enfoque y cuáles requieren ser adaptadas. Por ejemplo, en el caso de un portal centralizado de seguridad, desde una perspectiva global es clave que dicho portal exista y sea utilizado por todos los equipos. Sin embargo, desde una mirada más local, lo importante es medir si el equipo conoce el portal, lo utiliza y en qué medida lo aprovecha en su día a día.

Además, es fundamental considerar que las recomendaciones y trampas comunes incluidas en la Guía Ágil no forman parte del modelo original de OWASP SAMM. Son precisamente estos elementos los que permiten transformar el modelo tradicional en una herramienta verdaderamente útil para contextos ágiles.

En resumen, la medición basada en los niveles originales de SAMM debe complementarse con el enfoque de la Guía Ágil, incorporando el contexto del equipo y su forma de trabajo. Solo así se puede repensar efectivamente cómo aplicar SAMM en entornos ágiles y orientados a DevSecOps.

Respaldo de buenas prácticas de seguridad #

Aunque puede parecer un detalle menor, contar con un modelo de referencia es esencial para respaldar y priorizar las prácticas de seguridad de forma objetiva. Esto asegura que el roadmap y la planificación no dependan únicamente del criterio de un consultor o de decisiones aisladas, sino que se basen en un enfoque estructurado y validado por la comunidad.

Al basarse en el modelo, se parte de un punto de consenso: no se trata simplemente de hacer “lo que parece correcto”, sino de avanzar con base en un modelo que refleja el aprendizaje colectivo de toda una comunidad. Esto aporta legitimidad a las decisiones, evita improvisaciones y permite enfocar los esfuerzos en mejoras progresivas, medibles y alineadas con el contexto real del equipo.

Además, utilizar un modelo reconocido facilita la comunicación y justificación de decisiones frente a otras áreas, como gestión, producto o auditoría, fortaleciendo el compromiso organizacional con la seguridad.

Conclusión #

A diferencia del modelo completo de OWASP SAMM, la guía ágil deja de lado ciertas prácticas organizacionales y procesos a gran escala como Gobernanza y Métricas globales. Se enfoca en prácticas más tácticas que los equipos pueden adoptar directamente, como el modelado de amenzas, la especificación de requerimientos de seguridad o el mismo involucramiento y conocimiento en los temas de seguridad como tal. Su enfoque acotado permite ganar tracción rápidamente, identificar puntos críticos y priorizar mejoras sin depender de una transformación organizacional completa.

Por lo que vale la pena el uso de este modelo de madurez cuando estamos focalizando solo en los equipos de desarrollo ágil, ya que realmente puntualiza sobre temas que son cercanos a los equipos, aunque algunas mediciones, en mi opinión, aún están más orientadas a la organización que al equipo en sí por estar utilizando como base el mismo modelo de OWASP SAMM.

Sin embargo, es clave comprender que esta guía no reemplaza una estrategia integral de seguridad, que trabaja desde lo general hacia lo local. Pero es un punto de partida valioso para madurar desde lo local —el equipo— hacia una visión más holística de DevSecOps desde el mismo equipo.

Notas adicionales #

Estoy explorando cómo aplicar esta misma lógica de “madurez puntual” en otros ámbitos, por ejemplo, en la forma en que se diseñan e implementan los pipelines de CI/CD desde una perspectiva segura. No me refiero a incluir validaciones de seguridad para los componentes que viajan en el pipeline, sino más bien a que la forma de desarrollar los pipelines sea considerando la seguridad. Ya di con algunas mediciones que estan públicadas pero me falta recopilar un poco mas para poder armar lo que necesito.

También estoy considerando compartir la versión adaptada de evaluación que creé para la guía ágil. ¿Te interesaría probarla?

Por último, me encantaría conocer cómo otras personas están usando OWASP SAMM o la guía ágil en sus equipos. ¿Tienen alguna forma rápida de medir el nivel de madurez en seguridad que están alcanzando en sus procesos de desarrollo? ¿Consideras que es correcto medir de manera individual a un equipo?